Skip to content

docs(maintenance): create upgrade guide from v1 to v2 #1994

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Feb 14, 2024

Conversation

dreamorosi
Copy link
Contributor

@dreamorosi dreamorosi commented Jan 30, 2024

Description of your changes

This PR introduces a new version of the upgrade guide that now contains all the details for migrating from v1 to v2.

While the page is expected to be exhaustive at launch, we expect and are committed to treat it as a living document and complement it with additional sections/details as needed based on customer feedback post release.

Related issues, RFCs

Issue number: #1983

Checklist

  • My changes meet the tenets criteria
  • I have performed a self-review of my own code
  • I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my change is effective and works
  • The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

  • I have documented the migration process
  • I have added, implemented necessary warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

@dreamorosi dreamorosi self-assigned this Jan 30, 2024
@boring-cyborg boring-cyborg bot added the documentation Improvements or additions to documentation label Jan 30, 2024
@pull-request-size pull-request-size bot added the size/L PRs between 100-499 LOC label Jan 30, 2024
@dreamorosi dreamorosi linked an issue Jan 30, 2024 that may be closed by this pull request
1 task
@dreamorosi dreamorosi marked this pull request as ready for review January 31, 2024 17:00
@dreamorosi dreamorosi requested review from a team, sthulb, hjgraca, am29d and heitorlessa January 31, 2024 17:00
@dreamorosi dreamorosi requested a review from am29d February 5, 2024 12:47
Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first quick pass. Will continue editing on ESM section after lunch.

Added explanations to editing so you can learn about the process too :)

Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improved the ESM and ESM compatibility section ;)

I'll continue tomorrow!

image image

@heitorlessa
Copy link
Contributor

Continuing the review in 2m ;)

Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more early editing feedback with some tips on how you can lead with the answer, explain reusable concepts upfront, and shorten / merge paragraphs for a quicker understanding.

[more soon]

Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log sampling reviewed.

A quick tip is to use a table for enumerating more than one behavior change. A table helps the eye to quickly glance at each key change, along with a before/after without a code snippet per se.

Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final review before our writing tips session tomorrow to walk through the written feedback here.

I'll leave the last section so you can apply before/after and tips I shared earlier.

@heitorlessa
Copy link
Contributor

Sharing my mental model after our live session going through these PR comments with the reasoning why.

flowchart LR
    Verbose[Start verbose] --> Cut[Keep the meaning, not the length] --> Cues[Use formats and visual to your advantage] --> Tenets[Remember our progressive tenet and our global audience]
Loading
  1. Start verbose like you did - explain as much as possible without worrying whether is too much or not. It's easier to edit with as much context than without context.
  2. Try cutting words that when removed don't change the message you want to convey. For example, in your codebase, underlying directory structure of the Powertools for AWS Lambda (TypeScript).
  3. Use synonyms to vary your vocabulary, including shorter ones to reduce sentence length.
  4. Make use of new paragraphs when you have multiple points to make. If context is needed for each key point, try using bullet points - key point. followed by context.
  5. Try different text formats and markdown elements to make your information more easily digestible. For example, use tables when enumerating breaking changes.
  6. Use visual cues like diagrams and anners (sparingly) to bring key information upfront like whether to continue reading or not.
  7. Use code annotation for code lines that could use additional context with rich text _(links, etc.).

Last but not least, rely on these for judgement when to accept suggestions or continue editing it:

  1. Progressive tenet. Treat our docs like a product that is always becoming. We don't need to provide every piece of information upfront, since no one has such large working memory. Apply the progressive tenet so there is something for everyone - from beginners to advanced to heroes (80/20%).
  2. Global English. We have a global audience with the vast majority not being native English speakers. Use shorter sentences, simplify your vocabulary where needed, and avoid the temptation of deferring a short explanation to yet another link (e.g., tab hell).
  3. Limit reviews. Write verbose, edit yourself, then seek review from a limited number of people (1, 2 max in our context). Rely on our tenets, global English, and your gut by putting yourself in the customers shoes -- is this easy to grasp and enough for me to get going OR do I need to block my time do digest what I need to be productive?

Hope that helps <3

dreamorosi and others added 2 commits February 9, 2024 16:25
Co-authored-by: Heitor Lessa <[email protected]>
Co-authored-by: Heitor Lessa <[email protected]>
Copy link

Quality Gate Passed Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

@heitorlessa
Copy link
Contributor

Reviewing the last changes :)

@heitorlessa heitorlessa changed the title docs(maintenance): create upgrade guide docs(maintenance): create upgrade guide from v1 to v2 Feb 14, 2024
Copy link
Contributor

@heitorlessa heitorlessa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shiiiiip it! This is super exciting -- Thank you @dreamorosi and @am29d for the incredibly hard work you put into this!

@heitorlessa heitorlessa merged commit b18a8c7 into main Feb 14, 2024
@heitorlessa heitorlessa deleted the docs/upgrade_guide branch February 14, 2024 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation size/L PRs between 100-499 LOC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Docs: Create upgrade guide in docs
3 participants